feat(custom-model): generate Run-menu entries from saved endpoint profiles - #430

Thanks for picking this up, and for reading the merge comment on #393 as an actual invitation rather than a pleasantry. The shape is right: generating the entries off capabilities.customModelInjection instead of hardcoding a duplicate per harness is exactly what I meant, injecting the capable-CLI list at render so the frontend never carries an id list is better than what I had in mind, and hiding the section for remote and docker cases because the apply route already refuses both is the correct instinct.

It is still a draft so I am reviewing it as one. The backend, the docs and the architecture are sound. The frontend half does not currently work, and I want to be specific rather than vague about it, because none of it needs a redesign. Every item below is small and local.

You were honest up front that no browser test was possible on your box ("this box has no tmux"). That is exactly where the damage landed, so it is worth saying plainly: three of these would have shown up on a single page load.

First, credit where it is due: your last commit (38e1acfe) already fixed what was the third blocker, the red test/server-index-title.test.ts. CI is green on the current head. Three remain.

1. Every generated inline onclick is unparseable, so nothing is clickable (session-ui.js:585, and the three per-row buttons in settings-ui.js).

onclick="app.runCustomModelEntry(${JSON.stringify(cli.id)}, ...)"

JSON.stringify emits double quotes and they sit inside a double-quoted HTML attribute, so the attribute terminates at the first one. Parsed with jsdom the button comes out with onclick="app.runCustomModelEntry(" and the rest of the call shredded into junk attribute names. That does not compile, btn.onclick is null, and a click fires nothing. This hits every entry the picker generates and all three of Discover, Edit and Delete.

The repo already has the right idiom four lines away in the same file: onclick="app.deleteCase(${escapeHtml(JSON.stringify(c.name))})" (session-ui.js:3878, also :3870, :3874, :4050, :4057). escapeHtml turns the quotes into ", which the attribute survives and the JS parser sees as quotes again.

Fix it that way rather than by reordering quotes, because there is a second reason: modelId is the only value in that button reaching HTML unescaped, and it comes from the remote endpoint's own /v1/models response. A model id containing > terminates the <button> early and whatever follows parses as markup. The endpoint is admin-configured so this is not a remote-attacker path, but it is live HTML injection through data the server does not control, and escapeHtml closes it for free.

2. The endpoint list is read as a bare array, but the wire carries the envelope (session-ui.js:571,576 and settings-ui.js:2509,2511). GET /api/model-endpoints returns a bare array from the handler, and then the preSerialization hook in server.ts:769-784 wraps every /api payload that is not already an envelope, arrays included. I replayed that exact hook against a Fastify route returning an array: the wire body is {"success":true,"data":[...]} and Array.isArray(body) is false. So Array.isArray(hosts) is always false in production, the Custom Endpoints section hides itself unconditionally, and _customModelHosts is always [], which means the settings panel permanently reads "No endpoints yet". Even with item 1 fixed the feature is invisible.

const hosts = await this._apiJson('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/api/model-endpoints'); fixes it; api-client.js:44 exists for this and unwraps {success,data} already. CLAUDE.md states the rule directly under External CLI modes: "run*() in session-ui.js MUST unwrap the {success,data} envelope; reading the raw shape silently breaks the run."

Worth knowing why no test caught it, since it is not your fault: createRouteTestHarness builds a bare Fastify instance with only the route module and the error handler, no preSerialization hook, so custom-model-routes.test.ts:37's expect(res.json()).toEqual([]) is correct in the harness and wrong on the wire. That is a real gap in the harness and I will look at it separately.

3. A failed launch applies the endpoint to whatever session was already open, and restarts it (session-ui.js:628-651). The comment assumes a failed run*() leaves activeSessionId null. It does not: every run*() handles its own errors and returns normally. runDeepSeek() returns early when dsh is missing or has no pane-capable profile; runClaude() wraps its body in try/catch and ends with _reportSessionLaunchError. In both cases no session was created, and the code then POSTs /api/sessions/<the session the user was already looking at>/custom-model, which points that unrelated session at the endpoint and calls restartCli(), killing the pane and relaunching the CLI. isBusy() blocks it mid-turn, but an idle session, which is most of them, gets silently re-pointed and restarted while the toast says "Pointed at ..., restarting" for a launch that never happened.

Either have the runner hand back the id it created, or snapshot before and require it to have changed:

const before = this.activeSessionId;
await runner();
const sessionId = this.activeSessionId;
if (!sessionId || sessionId === before) return;

The snapshot form is a heuristic (it also declines if a run legitimately re-selects the same session), but declining to apply is the safe side of that trade.

Two majors:

4. It bypasses the Run launch in-flight lock. runCustomModelEntry calls runClaude() and friends directly instead of going through run(), so _runInFlight is never set and #runBtn is never disabled. CLAUDE.md, Run launch synchronization: the lock exists so a double click cannot create duplicate sessions with the same w<n>-<case> name. Closing the menu at the top makes a double click on the entry itself hard to hit, but the lock guards the other direction too: clicking the main Run button while a custom-endpoint launch is still resolving starts a second concurrent launch. Set and clear _runInFlight around the call, or route through run(). Related, same function: mutating #tabCount to '1' and restoring in a finally works, but it visibly flips the user's input for the duration, and if two launches ever overlap (which the missing lock allows) the restore can stomp.

5. No test for any of the new frontend behaviour. Three of the four blockers are DOM-level facts that need no Playwright and no tmux. test/home-sessions.test.ts is the precedent: it loads a frontend module with node:vm against a fake DOM and runs inside the CI gate. A test in that shape over _refreshCustomModelRunOptions, given a fake menu, a stubbed fetch and two endpoints, asserting that a button exists and its onclick attribute parses, would have caught items 1 and 2 on your own machine.

Minors, worth doing while you are in here:

• The hardcoded runners map contradicts the PR's own design. The point of injecting the capable list off the registry is that a CLI whose injection recipe lands later needs no frontend change, but the click handler dispatches through a hardcoded eight-entry object, so such a CLI gets a generated entry that toasts "No run function for mode X". It matches the eight capable CLIs today, so this is latent rather than broken. run() already owns this dispatch.
• Generated entries ignore whether the CLI is installed. _refreshRunModeAvailability hides a stock entry when isCliAvailable(mode) is false; the generated ones are built afterward and never gated, so on a box with no codex the stock Codex entry is hidden while "Codex (llama.cpp)" is still offered and fails at launch. A .filter((cli) => this.isCliAvailable(cli.id)) matches existing behaviour.
• The CRUD panel is not gated on the toggle, but both docs say it is. docs/custom-model-endpoints.md says turning the setting on reveals the panel; nothing reads customModelEndpointsEnabled for visibility, so the list, the Add button and the form always render. Gate it, rather than rewording the docs: with the feature off, the panel is a list of things that do nothing. Also loadCustomModelEndpointsForSettings() is called unconditionally from openAppSettings(), so every settings open fires the GET even with the feature off.
• The design doc still describes the superseded UI. docs/custom-model-endpoints-plan.md section 4 still specifies a separate #customModelBtn toolbar selector, and CLAUDE.md points readers at that file as the design reference. A "superseded by the Run-menu picker" note at the top of that section keeps it honest.
• The API key round-trips through the browser on every edit. GET /api/model-endpoints returns hosts verbatim including apiKey, and the editor re-sends it to implement "blank means unchanged". The comment saying the key is never round-tripped back is true of the input element but not of the request. That store is 0600 precisely because it holds credentials. This is pre-existing route behaviour from feat: Custom Model Endpoint Profiles (local or cloud, all harnesses) #393 rather than something you added, and the exposure is bounded, so it is not a blocker, but the clean fix lives on the server: let PUT treat an absent apiKey as "keep the stored one" and stop returning it on GET. Worth doing while this area is open. Same function: a blank field can only keep a key, never clear one.
• No way to un-point a session. The apply route accepts {clear: true} and the bookkeeping supports it, but no UI reaches it, so the only way back to the native backend is curl or deleting the session. Your docstring knows this; the wiki page does not mention it under "What it does not do".
• The panel offers writes to non-admins in multi-user mode. Endpoint writes are admin-only, but Add/Edit/Delete render for everyone and a non-admin gets a 403 toast. The list is already empty for them, so hiding the controls when the list is empty and the user is not an admin matches how remote and Docker hosts behave.
• Invisible on phones. mobile-overview.js builds its own run picker from mo-mode entries rather than reusing #runModeMenu, so the section does not appear there. Not a regression and not claimed, but the docs should not say "the Run menu" without qualification.

Nits: the index.html comment names _renderCustomModelRunOptions() and the function is _refreshCustomModelRunOptions(); styles.css:16221 uses rgba(0,0,0,0.12) on .set-inline-form, and CLAUDE.md records that hardcoded black alphas turned the settings preview into a grey slab on the light skins, so use a skin token; .run-mode-custom-models gets no CSS so the menu's gap: 2px does not apply between generated entries; server.ts:1609 does JSON.stringify() into a <script> body without escaping </script>, and CliEntry.label is a 60-char string a user's own clis.json could set, so .replace(/</g, '\\u003c') costs nothing (the neighbouring __codemanCliAvailable injection is booleans only, which is why it never needed it); no zh-CN entries for the new settings group; and /api/model-endpoints plus defaultModelId are still absent from docs/api-reference.md.

The backend piece (defaultModelId, refusing a value that is not one of the endpoint's discovered models, dropping it on a fresh discovery) is good and I have no notes on it.

Items 1, 2 and 3 are what I need before this comes out of draft. It is not going into the release I am assembling now, which is fine for a draft. Ping me when it is ready and I will take another pass.

I've been manually validating this one, it might take a few days as it's having problems injecting the right keys & context windows for different models when using llama-swap etc.
Stay tuned :)

I've done a heap of manual testing on this one a including llama.cpp and model switching with llama-swap. Added smarts such as warning that you're about to unload another model that's currently in use by another terminal etc :)

@Ark0N it's ready to review

I've started planning Codeman's CLI-registry frontend follow-up (PR B2) but found conflicts with this PR branch, so the plan now waits to apply this branch first and then I'll complete that original PR

Thanks for this, and for the amount of real-hardware testing behind it. This turns #393's backend into a usable feature: a generated Custom Endpoints section in the Run menu, full endpoint CRUD in App Settings, a no-restart launch path for the seven non-Claude harnesses, and a pile of llama-swap handling (swap conflicts, context-window floor, live backend log line) that clearly came from actually running it rather than from reading the code.

Two things I would like fixed before merge, then some smaller notes.

1. Editing an endpoint wipes the discovered context lengths and sizes (src/web/public/settings-ui.js:2656).

PUT /api/model-endpoints/:id replaces the whole record (custom-model-routes.ts:709 carries over only apiKey), and the editor's body sends models and lastDiscoveredAt but not modelContextLengths or modelSizesGB. So renaming an endpoint, or changing its default model, silently drops both. That turns off the two things this PR added: exceedsSafeContextFloor() reads endpoint.modelContextLengths?.[modelId] and returns false for an unknown length, so the context-window warning stops firing, and CLAUDE_CODE_MAX_CONTEXT_TOKENS stops being injected. The 5-minute sweep only re-learns a context length for a model llama-swap currently reports loaded, so for every other model it stays gone.

I confirmed this with a throwaway route test: discover a model, assert the store holds its context length and size, PUT the exact body saveCustomModelHostFromEditor() builds, and both fields come back undefined.

The schema comment at schemas.ts:1947 says those fields are accepted "so a client round-tripping the GET response back through PUT (edit-save) doesn't drop it", so the intent was already right. Either add them to the editor's body next to models, or (my preference, since it cannot be forgotten by the next caller) have the PUT handler merge the server-populated fields from the stored record the way applyStoredApiKey merges the key. A route test pinning "a PUT that omits them keeps them" would be worth having.

2. custom-model:swapped-out is broadcast unscoped (src/web/server.ts:2786).

The payload carries sessionId, sessionName, endpointId, previousModel and currentlyLoadedModel, and deriveSseHint (server.ts:2358) matches by event prefix. custom-model: is in none of its lists, so it falls through to undefined and canDeliver() returns true for every client. In multi-user mode that means everyone gets a toast naming another user's session and models. Adding 'custom-model:' to SESSION_PREFIXES is the whole fix: the payload already has sessionId, so the existing owner resolution and the sessionScoped: true fail-closed default work as-is, and single-user behaviour does not change.

3. setCustomModel() gets the merged env, which puts CLAUDE_CODE_EFFORT_LEVEL back (src/web/routes/session-routes.ts:3740).

qsCustomModelEnvOverrides is the caller's envOverrides plus the injected ones, and setCustomModel() merges its second argument straight into _envOverrides. The Session constructor strips CLAUDE_CODE_EFFORT_LEVEL out on purpose (session.ts:857) because as an env var it hard-locks in-session /effort, and re-merging the pre-constructor object puts it back. Passing cmApplied.envOverrides instead fixes it; the constructor has already applied the full set, and the bookkeeping only ever needs the injected keys.

4. The one-shot path hardcodes pi/grok/omp (src/web/routes/session-routes.ts:3708-3726).

The restart path does the same job generically off entry.launch.legacyConfigField (Session._withCustomModelLaunchModel, session.ts:1943). The quick-start path re-does it as three mode === '<id>' branches plus a new ALLOWED_BRANCHES entry. All three are covered today, but a CLI that declares customModelInjection.launchModel later will be offered by the picker (which reads capabilities), launch one-shot, and silently get no --model, running on its own default provider with nothing reporting it. Reusing legacyConfigField lets the allowlist entry go away too.

5. Sticky error toasts are now app-wide (src/web/public/panels-ui.js:5500).

The reasoning is right for the new custom-model messages, but the default now applies to all 133 showToast(..., 'error') call sites, and .toast-container has no cap, no max-height and no overflow, and showToast() never evicts. A repeatedly failing path (a flapping SSE reconnect, a poll loop) stacks sticky toasts off the bottom of the viewport where they cannot be read or dismissed, and on a phone that is only a few failures. I would either cap the container or scope the sticky default to the call sites that need it with an explicit { duration: 0 }.

Smaller things I will most likely just fix at merge:

• GET /api/model-endpoints/:id/running-status (custom-model-routes.ts:760) has no admin gate, so a non-admin can tell a real endpoint id (200) from an unknown one (404) and read logLine, which is the backend process's own stdout including on-disk model paths. Your comment makes a fair case from the apply route being ungated; I want the logLine half to be a conscious decision.
• docs/api-reference.md has been run through Prettier on top of the real additions (tables realigned, *x* to _x_, JSON re-indented), and the reflow de-indented continuation lines in unrelated bullets around the approvals, intent and voice sections. docs/ sits outside Prettier's scope on purpose. Reverting those hunks would make the doc diff reviewable.
• The quick-start context and swap warnings return after the case directory has been created and scaffolded (session-routes.ts:3609), so cancelling leaves an empty case behind.
• pumpLlamaSwapLogTail's finally (custom-model-routes.ts:438) deletes by key unconditionally, so an aborted pump finishing after a newer entry was created deletes that newer entry and orphans its stream. Guarding with an identity check covers it.
• Cancelling a warning on the one-shot path throws through run<Mode>(), so a deliberate cancel shows as a red "Failed to start X" toast. The restart path gets this right with an info toast.
• The phone overview's Run picker does not render the Custom Endpoints section, so the feature is desktop-only right now. Worth a line in the docs.

On the rest: the registry discipline in the picker, the endpoint store staying the only source of env values, the key never reaching the browser, the /props to /running context-length correction and the /logs to /api/events one are all exactly right, and the server-side test coverage is the best part of the PR. I also checked that rmSync recursive does not follow the projects symlink, so removeConfigDir() cannot touch the real ~/.claude/projects, which was the one place a mistake here would have been expensive.

Checks on my side: typecheck, lint, check:frontend-syntax, format:check and check:public-assets all clean, and the full npm test is green (392 files, 7446 tests, exit 0).

Push fixes for 1 to 4, tell me which way you want 5, and I will take another pass. A Playwright run over the picker and the settings panel before merge would close the gap you already flagged.

@Ark0N All done

Pushed 1f32128c addressing the four pre-merge blockers plus item 5:

1. Edit wipes context lengths/sizes — PUT /api/model-endpoints/:id now merges modelContextLengths/modelSizesGB back in from the stored record server-side (mirroring applyStoredApiKey), so the editor no longer needs to round-trip them and a rename/default-model edit can't silently drop the context-window floor check or CLAUDE_CODE_MAX_CONTEXT_TOKENS injection.
2. Unscoped custom-model:swapped-out broadcast — added 'custom-model:' to SESSION_PREFIXES in server.ts, so it now resolves the owner from sessionId like every other session-scoped event instead of going to every connected client.
3. CLAUDE_CODE_EFFORT_LEVEL re-merge — the quick-start path now passes setCustomModel() only the endpoint's own injected env vars (cmApplied.envOverrides) rather than the full merged set, matching what the restart-in-place route already did — the full set was putting the effort env var back right after the Session constructor stripped it.
4. Hardcoded pi/grok/omp branches — the quick-start launch-model override is now applied generically off the registry's legacyConfigField, mirroring Session._withCustomModelLaunchModel, so a CLI whose custom-model injection lands later doesn't need a frontend-adjacent code change here too. Dropped the now-stale ALLOWED_BRANCHES entry in cli-registry-no-id-branching.test.ts.
5. Sticky toasts — reverted the blanket "every error toast is sticky" default (no cap on .toast-container, no eviction) back to a flat 3s, and made the one message that actually needs it — a failed custom-model apply — opt in explicitly with duration: 0 at its own call site.

All directly relevant suites pass (custom-model-routes, quick-start-custom-model, session-custom-model, cli-registry-no-id-branching); typecheck and lint clean. Ready for another pass.

Thanks for this, and for going back to real hardware rather than stopping at the tests: the /props n_ctx discrepancy, /logs carrying only the proxy log, the 36.4K Claude Code floor and llama-swap needing an actual inference request to swap are all things nobody finds by reading code. This turns #393 into a feature people can use: a Run menu section generated off the registry, the settings CRUD panel, and a one-shot launch path so seven of the eight harnesses no longer boot native and then restart.

Full npm test is green here (392 files, 7446 tests), as are typecheck, lint, check:frontend-syntax and format:check. One thing needs fixing before I merge, plus a few small ones.

The centred status banner never actually goes away. src/web/public/styles.css:8560 declares .center-status-banner { display: flex } with no [hidden] re-assert, so the dismiss() in _showCenterStatus (src/web/public/panels-ui.js:5591) sets el.hidden = true and nothing happens: an author-level display: flex beats the UA [hidden] { display: none }. The card stays laid out at the viewport centre with opacity: 0, and opacity: 0 is still hit-testable, while .center-status-text, .center-status-cancel and .center-status-close each set pointer-events: auto at z-index 10001. I reproduced it in headless chromium against your stylesheet: after dismiss() the element computes display: flex, opacity: 0, a 442x67 rect, and document.elementFromPoint at the centre of the screen returns .center-status-text. Since _runCustomModelEntryViaRestart shows and always dismisses this banner on every Claude custom-model launch (session-ui.js:893, dismissed at :934, :954, :963, :978, :984), one launch leaves an invisible 442x67 click blocker dead centre over the terminal until the page is reloaded. The fix is the one the rest of the stylesheet already uses (.home-sessions[hidden] at 15706, .offline-overlay[hidden] at 15551):

.center-status-banner[hidden] {
  display: none;
}

Please add that plus a small assertion so it stays fixed. test/custom-model-run-menu-ui.test.ts already has bootAppWithRealCenterStatus(), or a stylesheet assertion in the style of test/home-sessions.test.ts works too. CLAUDE.md records this exact trap for .home-sessions, and its Z-index layers list is worth a line for the new banner (10001) and the two modals at 10010 while you are there.

The changeset still advertises the sticky-toast default you reverted. .changeset/run-menu-custom-model-picker.md:10 says "Toasts now default to sticky with a close button", but 1f32128c put the flat 3s default back and moved the one message that needs reading to an explicit duration: 0. That sentence goes straight into CHANGELOG.md and the release notes. Same claim in CLAUDE.md:230 ("showToast() now defaults to STICKY") and in the .toast-message comment at styles.css:8529. docs/custom-model-endpoints.md:202 is fine as written.

Smaller things, happy to take them in the same push:

• docs/api-reference.md:562 says discovery failures answer 502 OPERATION_FAILED; OPERATION_FAILED is 422 (src/types/api.ts:86), which the table at line 63 of the same file already states.
• src/web/server.ts:2764: the 5-minute re-discovery sweep never reads customModelEndpointsEnabled, so turning the feature off still leaves Codeman polling every saved endpoint forever. Reading the setting inside the callback would settle it.
• docs/api-reference.md picked up a full Prettier pass (table padding, *x* to _x_, JSON re-indent), and docs/** is outside npm run format's glob on purpose. It is about half that file's diff and it hides the real doc change, so reverting the formatting-only hunks would help.

One design question rather than a bug: confirmed: true currently answers both gates. Because the context-window check runs first (session-routes.ts:1226 then :1256, and :3613 then :3636 on quick-start), clicking "Launch anyway" on the context warning also skips the llama-swap "this will unload it for session X" check, so the user takes the model away from another session without being asked, which is the thing that warning exists to prevent. The new 20s displacement sweep catches it afterwards, so it is a surprise rather than a silent failure. I would rather have two flags, or the swap check running first. Your call; if you want to keep one flag, say so and I will leave it.

One more worth a sentence in the docs: CLAUDE_CONFIG_DIR relocates the whole .claude tree, not just transcripts, so a custom-model Claude session also loses the user's global settings.json, user-level skills (the codeman agent skill included), user-level agents and commands, and MCP servers from ~/.claude.json. That is probably a fine trade for "point this session at my local llama.cpp", but better stated than discovered.

Push the banner fix and the changeset/CLAUDE.md wording and I will merge. Worth a npm run test:browser pass diffed against master first as well, same as any frontend change, since the gate cannot see that suite.

@Ark0N Pushed 9982a132 addressing this pass:

Blocker fixed — the .center-status-banner dismiss bug. Added .center-status-banner[hidden] { display: none; } (same trap as .home-sessions[hidden]), plus a regression test in test/custom-model-run-menu-ui.test.ts pinning the CSS rule via bootAppWithRealCenterStatus()'s neighbouring describe block. Also added the banner (10001) and the swap-confirm/context-warning modals (10010) to CLAUDE.md's Z-index layers list while I was there.

Stale sticky-toast wording fixed in all three places you found it: the changeset, CLAUDE.md, and the .toast-message comment in styles.css. All three now describe the actual behaviour (duration: 0 at the one call site that needs it) instead of the reverted blanket default.

Smaller items, all done:

• docs/api-reference.md: discovery-failure status corrected to 422 OPERATION_FAILED.
• server.ts's periodic re-discovery sweep now reads customModelEndpointsEnabled on every tick (new readCustomModelEndpointsEnabled() in custom-model-routes.ts, same shape as readPlanUsageTelemetryEnabled) and skips entirely while the feature is off.
• Reverted the formatting-only Prettier pass on docs/api-reference.md by re-merging just the new Custom Model Endpoints section onto the pre-PR file — verified the result is formatting-only against the prior version and content-only-addition against the merge-base, so nothing else moved.
• docs/custom-model-endpoints.md now says plainly that the isolated CLAUDE_CONFIG_DIR also drops the user's global settings.json, user-level skills/agents/commands, and ~/.claude.json MCP servers — only projects comes back.

Design question (confirmed: true answering both the context-window and llama-swap-displacement gates): keeping the single flag, as you offered. Splitting it or reordering the checks is real behavioural surface I have no way to verify against a live llama-swap server from here, and the 20s displacement sweep still catches the resulting swap after the fact — a surprise, not a silent failure. Happy to revisit if you'd rather I split it.

One gap to flag honestly: I could not run npm run test:browser in this environment — no tmux, and the Playwright chromium binary isn't downloaded here. None of that suite's files touch anything this fix changes (CSS visibility rule, a settings read, doc wording), but it still deserves a real pass before merge, same as any frontend change — I don't have write access to this repo to trigger CI myself, so that pass and the actual merge are over to you.

typecheck, lint, check:frontend-syntax and format:check are all clean; the directly relevant suites (custom-model-run-menu-ui, custom-model-routes, home-sessions) pass in full (88/88).

@Ark0N All done

Thanks for this, and for the depth of the live validation behind it. This turns #393's backend into the whole clickable feature: a Run-menu section generated off the CLI registry, the settings CRUD panel, a one-shot launch path for the seven non-Claude harnesses, and the llama-swap swap, context-floor and displacement handling that makes it behave when the model is not already loaded.

Typecheck, lint, frontend-syntax, format-check and the full npm test gate (7447 tests) are all green here, and the test coverage you added is genuinely good. Two things I would like fixed before merge, both small.

1. The loading banner hides itself about 200ms after it appears, on the Claude path (src/web/public/panels-ui.js:5588)

_showCenterStatus reuses one shared DOM node, and dismiss() schedules el.hidden = true 200ms later with nothing cancelling that timer. In _runCustomModelEntryViaRestart (src/web/public/session-ui.js:977) you call switchingToast.dismiss() and then hand straight off to _watchLlamaSwapLoading, which awaits one same-origin /api/model-endpoints request (5 to 30ms locally) before opening the new banner. The old timer then fires and hides the new one, so the whole model-load window runs with no progress text, no llama.cpp log line and no reachable Cancel button. I reproduced it in JSDOM against the real _showCenterStatus: open, dismiss, reopen 20ms later, and el.hidden is true 300ms on.

Please park the pending timeout on the element and clear it at the top of _showCenterStatus:

if (el._hideTimer) { clearTimeout(el._hideTimer); el._hideTimer = null; }
...
const dismiss = () => {
  el.classList.remove('show');
  el._hideTimer = setTimeout(() => { el.hidden = true; el._hideTimer = null; }, 200);
};

A case in the existing _showCenterStatus Cancel button (real DOM, not the stub) block would pin it, since that harness already loads panels-ui.js.

2. The swap-conflict warning names other users' sessions (src/web/routes/session-routes.ts:1257 and :3637)

Both affectedSessions scans walk the whole ctx.sessions map with no ownership filter, and the ids and names come back to the caller and get rendered in the confirm dialog. Applying a custom model is ungated for any session owner by design, so in multi-user mode a non-admin pointing their own session at a shared endpoint learns other users' session names, which with autoNameSessions on are their prompts. canAccessOwned is already imported in that file:

.filter((s) => ... && canAccessOwned(getAuthUser(req), s.owner))

A foreign session still blocks the swap, it just is not named. A two-owner test in test/routes/session-custom-model.test.ts would be good alongside it.

A few smaller things I will pick up separately or that can ride along if you are touching these files anyway:

• src/web/server.ts:1236: boot recovery calls applyCustomModelInjection without contextLength, so CLAUDE_CODE_MAX_CONTEXT_TOKENS drops out of the rebuilt _envOverrides after a restart and survives only because tmux retains the setenv. One line: pass endpoint.modelContextLengths?.[saved.modelId].
• src/web/routes/custom-model-routes.ts:450: pumpLlamaSwapLogTail's finally can delete a newer tail created for the same endpoint after this one was aborted, leaving a connection nothing can abort. Guard it with if (llamaSwapLogTails.get(host.id) === entry).
• Clearing a custom model removes every injected key by name, and CLAUDE_CONFIG_DIR is now one of them, so a session that had its own CLAUDE_CONFIG_DIR set through envOverrides (the per-client-account case) loses it and silently falls back to the default account. Worth at least a sentence in docs/custom-model-endpoints.md.
• In quick-start, the requiresConfirmation and requiresContextWarning returns land after the case-scaffolding block, so cancelling either dialog on a new case name leaves the directory behind.
• runCustomModelEntry's mode === 'claude' check is the one CLI-id branch left in the frontend. The static guard only walks TypeScript so it passes, and your reasoning for the split is sound, but a customModelInjection.launchStrategy field would retire it whenever this area is next touched.

On scope: this is a lot for one PR, and I know you flagged that yourself up front. I am not asking you to split it now, the commit history is readable and each piece is clearly downstream of making the feature work when you click it. Worth keeping in mind for the next one.

Send the two fixes and I will merge.

@Ark0N Pushed afb67544 with both fixes plus the ride-along items.

1. Loading banner hides itself ~200ms after reopening — fixed. Parked the pending hide timeout on the element (el._hideTimer) and clear it at the top of _showCenterStatus, per your snippet. Added a test in the existing Cancel-button describe block that reproduces your exact repro (open, dismiss, reopen 20ms later, advance past 200ms) — confirmed it fails on the old code and passes with the fix.

2. Swap-conflict warning naming other users' sessions — fixed, both call sites (session-routes.ts dedicated route and quick-start). The swap is still blocked pending confirmation regardless of ownership — a foreign session is just as real a disruption — but only sessions the caller can access get named back via canAccessOwned, same as you sketched. Added a two-owner test to test/routes/session-custom-model.test.ts covering both the foreign-owner (blocked, not named) and same-owner (named) cases.

Ride-along fixes, all done:

• server.ts boot recovery now passes contextLength into applyCustomModelInjection, so CLAUDE_CODE_MAX_CONTEXT_TOKENS is correctly rebuilt after a restart.
• pumpLlamaSwapLogTail's finally now deletes by identity, not just by key, per your guard suggestion.
• docs/custom-model-endpoints.md now notes that clearing a custom model removes CLAUDE_CONFIG_DIR by name too, so a session using it via envOverrides for a per-client account silently falls back to the default account on clear.

Left for later, as you yourself flagged: the quick-start case-scaffolding/cancel ordering (real reordering across a large handler — didn't want to touch that without a live re-test I can't do here) and the mode === 'claude' branch retirement behind a launchStrategy field (you said "worth keeping in mind for the next one").

typecheck, lint, and format:check are clean. Directly relevant suites: 111/112 passing (session-custom-model, quick-start-custom-model, custom-model-routes, custom-model-run-menu-ui) — the one failure is the same pre-existing Windows chmod-0600 assertion from earlier rounds (this dev box is Windows; not something introduced here).

As before I don't have write access to this repo to run CI or merge — that and a test:browser pass are over to you.

Thanks for this. It turns #393's backend into something people can actually use: a Run menu section generated off the CLI registry, full endpoint CRUD in settings, and a lot of hardening you clearly found by running it against a real llama-swap box rather than by reading the code.

Checks are green here: typecheck, lint, format:check, check:frontend-syntax and check:public-assets all clean, and the full npm test gate passes (397 files, 7527 tests). The coverage on the picker and the polling loop is better than most frontend PRs get.

A few things before this goes in.

1. The privilegedEnvKeys widening changes behaviour outside this feature (src/config/cli-registry/stock.ts:244-245).

Adding CLAUDE_CODE_MAX_CONTEXT_TOKENS and CLAUDE_CONFIG_DIR there does not do what the comment says. privilegedEnvKeys has exactly one consumer, ownerClampedEnvKeys() in src/session-env-clamp.ts:65, and that feeds the generic envOverrides clamp on POST /api/sessions, POST /api/quick-start and reboot-restore. No custom-model route reads it, and the injected values are merged after the clamp anyway, so this feature does not strictly need the entry.

What it does do, in multi-user mode for a non-granted owner: CLAUDE_CONFIG_DIR can no longer be set through envOverrides (that is the per-client-account feature from #255), and a persisted one is now dropped on reboot-restore, which silently switches that session to the default Claude account. It also makes src/session-env-clamp.ts:10-16 false, since that fileoverview states that claude's privileged keys are the five ANTHROPIC_* names and that a persisted record therefore cannot carry a clamped key.

I have decided this one rather than leaving it to you: keep both keys. types.ts:485 genuinely does say every traffic-redirecting var this feature introduces must be listed, and I would rather the rule stay literally true than carve an exception into it for the two keys that happen not to need it today. So the entry stays and the consequences get written down instead. What I need from you:

• correct the src/session-env-clamp.ts:10-16 fileoverview, which now states the opposite of what the code does
• correct the rationale comment at stock.ts:244-245, since "listed here only so the custom-model route clamps them" is not what the field does
• add a line to CLAUDE.md's CLAUDE_CONFIG_DIR gotcha saying it is admin-only in multi-user mode, and that a persisted one is dropped on reboot-restore for a non-granted owner
• add a claude clamp test next to the deepseek and omp ones, so the new behaviour is pinned rather than incidental

2. running-status returns more than it needs (src/web/routes/custom-model-routes.ts:805).

Leaving the route un-gated is fine, but it passes cmd through: the literal llama-server ... launch line, which carries model paths and can carry --api-key. cmd exists only so parseCtxFromCmd() can read it server-side during discovery; _watchLlamaSwapLoading reads only model and state. Please map to { model, state } in the route and keep cmd internal.

3. Two comments point at code that no longer exists.

src/custom-model-hosts.ts:71 still sends modelSizesGB readers to estimateModelLoad() in session-ui.js, which went away with the countdown. And src/web/routes/custom-model-routes.ts:802 plus src/web/server.ts:2815 still say "/logs tail" for what is now an /api/events tail, which reads oddly right next to the docs explaining why /logs was the wrong endpoint.

4. CLAUDE.md counts (CLAUDE.md:384 and :388).

sse-events.ts went from 158 to 159 and its own header was updated, but CLAUDE.md's SSE section still says "158 = 158". Same at line 388: running-status makes it custom-model (6) and ~234 handlers.

Smaller things, which I will most likely just apply at merge rather than send back:

• runCustomModelEntry branches on mode === 'claude' (session-ui.js:774). The no-id-branching guard only walks .ts files, so it cannot see frontend JS. Reasonable for now given what runClaude() carries, but a launchStyle field on the capability would keep the rule true and make the eventual claude conversion a data change.
• isCliAvailable() treats an unknown id as available, and __codemanCliAvailable only carries the stock ids, so a custom entry in clis.json that declares customModelInjection gets a menu row whose click falls through run()'s dispatch into runClaude() and launches a plain native Claude session with no error (session-ui.js:565).
• Both apply routes gate the context warning and the swap-conflict warning on the same confirmed flag, and the context check runs first, so "Launch anyway" on a too-small context also skips the "this will unload it for someone else's session" ask (session-routes.ts:1161 and :3554).
• Cancelling a swap or context dialog on the one-shot path comes back through _reportSessionLaunchError as a red failure; the restart path shows an info toast for the same action.
• pumpLlamaSwapLogTail's buffer only shrinks at a \n\n boundary (custom-model-routes.ts:435), so an endpoint that streams without frame boundaries grows it without bound. A cap would close that.

Do 1 as described above and fix 2, and I will take 3, 4 and the smaller list at merge. Nice work tracking the /props versus /running context discrepancy and the DeepSeek /v1 root cause down to the SDK source instead of guessing at them.

One scheduling note so you are not guessing: the next release is going out with the three small terminal and Run fixes that are ready now, and this is not in it. That is purely because it is a feature of this size arriving while a patch release was already being cut, not a verdict on the PR. Once 1 and 2 are pushed it goes in on its own, and it is the headline when it does.

@Ark0N Two things in this push: caught the branch up with master (22 commits, incl. the reboot-restore feature and the 1.30.0 release), and addressed this review round.

Merge: no conflicts — git auto-merged every overlapping file (CLAUDE.md, docs/api-reference.md, app.js, index.html, styles.css, routes/index.ts, session-routes.ts, schemas.ts, server.ts). Also had to regenerate config/clis.stock.json/install.sh's catalogue block, since the merge left them out of sync with the generator and cli-catalog-sync.test.ts was failing.

1. privilegedEnvKeys widening — done as you specified (keep both keys, document the consequences):

• Corrected session-env-clamp.ts's fileoverview, which said the opposite of what the code now does.
• Corrected the rationale comments in stock.ts:229-233 and :240-245 — the field's one consumer is ownerClampedEnvKeys() feeding the generic envOverrides clamp, not a custom-model route.
• Added the admin-only / reboot-restore-strips-it line to CLAUDE.md's CLAUDE_CONFIG_DIR gotcha.
• Added a "Claude multi-user clamp" test next to the DeepSeek/OMP ones in test/routes/session-custom-model.test.ts, pinning the strip for a non-granted owner and the no-op in single-user mode.

2. running-status no longer returns cmd. Now maps to {model, state} in the route; cmd stays internal to parseCtxFromCmd(). Added a test that plants a fake --api-key in a mocked cmd and asserts it never reaches the response body.

Left for you at merge, as you said: the two "points at removed code" comment fixes, the two stale CLAUDE.md counts, and the smaller list (the mode === 'claude' frontend branch, isCliAvailable()'s unknown-id gap, the shared confirmed flag ordering, the one-shot cancel toast severity, and the pumpLlamaSwapLogTail buffer cap).

typecheck, lint, format:check, check:frontend-syntax and check:lockfile are all clean. Directly relevant suites pass in full aside from the one pre-existing Windows chmod-0600 assertion flagged in earlier rounds (this dev box is Windows).

Both items from the last round are in, and the review of this head found one more that I am very glad it caught before this shipped.

The API-key trust seed never matched a real key. seedApiKeyTrustFile() wrote the key verbatim into customApiKeyResponses.approved, but Claude Code stores and compares only the last 20 characters (key.trim().slice(-20), applied on both the write and the lookup). For any real key the seed missed, and claude stopped at the interactive "Detected a custom API key in your environment" prompt, whose default is "No (recommended)". So the launch either hangs or silently refuses the key this feature just injected and falls through to an OAuth login the isolated config dir does not have.

The reason it got through both of us is worth writing down: DEFAULT_API_KEY is local-dummy-key, 15 characters, so on a keyless llama.cpp or llama-swap endpoint slice(-20) returns the whole string and the seed matches by accident. Every test used a short key too (my-key, k), so the suite could not see it either. Fixed via truncateApiKeyForTrustFile(), with a test using a 57-character key that also asserts the full credential never reaches that second file on disk. Cloud endpoints (OpenRouter, Azure) would have hit this immediately.

I also did the two-flag split I deferred last round. The context-floor warning and the swap-conflict warning shared one confirmed, and since the context check runs first, a user clicking "launch anyway" past a too-small context silently consented to evicting another session's model. They are questions about different people, so both routes now read confirmedContext and confirmedSwap independently. The legacy confirmed still means both, because it shipped in the API-only cut and an existing caller must keep working. The frontend answers each question with its own flag and accumulates them, on all three call sites.

Also taken at merge: the swap dialog no longer renders " are currently using ..." when multi-user scoping leaves the affected-session list empty (the swap is blocked regardless of ownership, only the names are scoped); the llama-swap log tails are closed in WebServer.stop() rather than only by the idle sweep whose interval that same teardown disposes; pumpLlamaSwapLogTail's unparsed remainder is capped, since it only shrank at a \n\n boundary; running-status's cmd is gone from docs/api-reference.md; the SSE and route counts are corrected; and the two comments pointing at removed code are fixed.

On the modelId validation: two places claimed the routes check it against the endpoint's discovered models and neither does. I dropped the claim rather than adding the check, because discovery can be up to five minutes stale and a 400 there would refuse a launch that actually works. CLAUDE.md now says the absence is deliberate.

And the changeset. It had grown to 1602 words of development log as the PR grew. That text becomes CHANGELOG.md and the release body verbatim, so I rewrote it as one user-facing account at about a fifth the length. Nothing was dropped that a user would care about; what went were the round-by-round process notes, which belong on this thread and are all still here.

Left as follow-ups, none of them merge conditions: architecture-invariants.md not carrying the privilegedEnvKeys widening you documented in CLAUDE.md, scripts/test-local-llm-harnesses.ts ignoring the four new env-kind injection fields, deleteCustomModelHost() swallowing a 403, the phone Run picker not mirroring custom entries, and runCustomModelEntry() branching on mode === 'claude' for the two launch paths (a launchStyle capability would keep the no-id-branching rule literally true and make the eventual claude conversion a data change).

A correction to what I told you last round: I said this was not going into the next release and would headline its own. It is going into 1.31.0 after all. You turned the round fast enough that holding it back would have been arbitrary, and the release was still open. A final review of the whole release tree is running now; assuming it comes back clean this ships today.

Thanks for the depth on this one, and for the two rounds of turning it around the same day.